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The  distributed  nature  of  command  and  control  requires  the  consideration  of  both 
processes  and  communications  in  the  formulation  of  requirements.  Cube  Tool  is  a 
methodology  used  to  derive  the  processing  and  communication  needs  for  each  system 
function.  An  approach  is  introduced  for  extending  the  applicability  of  Cube  Tool  to  the 
determination  of  requirements  for  C3I  systems.  First,  using  Cube  Tool,  for  each 
function,  a  Petri  Net  is  derived  that  models  all  processes  and  communications  for  the 
correct  execution  of  the  function.  Then,  for  a  given  scenario,  these  nets  are 
interconnected  and  the  steps  of  the  methodology  are  applied  again  to  derive  the  Petri  Net 
that  represents  the  mission-dependent  requirements  for  the  system. 
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INTRODUCTION 


The  determination  of  the  functional  requirements  of  a  system  is  usually  done  by 
representing  the  relationships  among  the  different  processes  which  have  to  take  place  for  the 
execution  of  a  mission.  When  the  systems  are  distributed,  the  requirements  must  includenot  only 
the  processes,  but  also  the  communications  among  the  different  parts  of  the  system.  The  Cube 
Tool  has  been  developed  as  a  methodology  for  deriving  the  processing  and  communication  needs 
for  each  system  function.  In  this  paper,  the  methodology  is  extended  to  address  the  determination 
of  system  requirements  and  their  representation  in  terms  of  Petri  Nets. 

Cube  Tool  (Toumes.  19SS)  is  a  methodology  developed  at  THOMSON-CSF  in  France  for 
the  design  and  the  analysis  of  C3I  systems.  The  methodology  allows  for  (1)  the  qualitative  and 
quantitative  design  of  the  architecture  of  C3I  systems:  (2)  the  determination  of  the  characteristics 
of  the  elements,  w  hich  tire  known  also  as  the  attributes  or  parameters  of  the  system;  and  (3)  the 
definition  of  the  general  plan  for  realization.  The  Cube  Tool  covers  the  application  domains 
which  are  common  to  all  C3I  systems:  communication,  information  processing,  information 
storage,  supervision/management,  and  man/machine  interface.  The  application  of  Cube  Tool  to 
the  design  and  the  analysis  of  a  system  is  done  in  four  steps,  as  shown  in  Figure  1. 

•  Identification  of  the  system  Functions  and  of  the  different  resources  tpersonnel  and 
hardware/software.)  involved, 

•  Functional  Analysis  for  the  determination  of  the  processing  and  information 
exchanges  for  each  function. 

•  Quantitative  Evaluation  of  Automated  Data  Processing  (ADP)  and  con.  .unication 
loads  in  workstations, 

•  Consideration  of  different  possible  architectures  through  the  allocation  of  the 
functions  to  different  sites. 

The  first  step  consists  of  defining  the  system  functions  from  the  missions  expected  to  be 
accomplished.  Each  function  is  divided  in  subfunctions.  Simultaneously,  the  resources  needed 
for  the  execution  of  these  functions  are  defined.  They  consist  of  personnel  and 
hardware/software  entities  such  as  databases  or  decision  aids  and  are  referred  to  as  Actors.  In  a 
second  stage,  a  functional  analysis  is  performed  for  each  function  in  a  three  dimensional  space 
with  axes  coresponding  to  functions,  actor  and  time.  In  this  framework,  subfunctions  are 
defined  as  a  collection  of  activities  with  their  interrelated  information  exchanges.  Each  function 
and  can  be  looked  on  three  different  planes  in  the  3-D  space:  Responsibilities  (Actors-Functions). 
Actions  (Actors-Time)  and  Sequences  (Functions-Time).  The  main  analysis  is  performed  in  the 
responsibility  plane.  Activities  are  differentiated  according  to  the  kind  of  processing  they 
represent.  For  each  function,  the  responsibility  plane  is  constructed  by  allocating  the  activities  to 
different  actors. 
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The  third  step  is  the  quantitative  evaluation  of  Automated  Data  Processing  and 
communication  load;,.  To  evaluate  the  processing  load,  each  activity  of  the  functional  structure  is 
defined  using  a  pseudo-code  formalism  close  to  PASCAL  or  ADA.  The  number  of  queries  to 
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databases,  me  kinds  of  display  and  the  required  computations  are  included  by  using  a  set  of 
primitive?,  garnered  in  a  dictionary.  To  evaluate  the  communication  load,  the  ways  information  is 
displayed  and  sent  are  analyzed  tor. the  incoming  and  outgoing  data.  A  processing  and 
communication  load  is  assigned  to  each  of  these  primitives.  The  processing  and  communication 
loac  quantification  for  each  activity  is  made  by  summing  the  loads  of  the  primitives  used  to 
deser 1  -e  the  execution  of  this  activity.  Simultaneously,  a  quantification  is  made  for  the  maximum 
response  time  to  determine  the  minimum  processing  power  threshold.  By  summing  these 
estimates  of  each  logical  group  (which  is  the  set  of  activities  related  to  a  given  system  function 
and  performed  by  a  single  actor.)  the  number  and  type  of  workstations,  the  processing 
requirements,  the  number  of  database  updates  and  retrievals  and  the  load  associated  with 
processing  and  related  communication  flows  can  be  determined. 

The  last  stage  is  the  investigation  of  different  architectures  through  the  allocation  of  logical 
groups  to  different  sites.  Generic  sites  are  first  defined  by  gathering  logical  groups  meant  to 
operate  together  and  sufficient  to  constitute  an  independent  node.  This  is  done  to  check  data 
coherency.  Then,  the  logical  groups  with  their  associated  loads  are  assigned  onto  different  sires 
according  to  the  areas  of  responsibilities  and  interests  specific  to  each  logical  group  and  to  the 
different  modes  of. operation  (normal  and  backups).  Within  these  new  system  sites,  the  load  is 
reallocated  to  the  different  workstations  according  to  the  type  of  processing  (scientific  vs.  expen 
system)  and  the  security  requirements.  Different  architectures  can  be  obtained  and  the  selection  is 
made  according  to  criteria  such  as  cost  or  ease  of  implementation. 

The  first  two  stages,  which  are  essential  for  the  specification  of  the  requirements  of  a  system, 
are  described  in  detail  in  the  next  section. 


FUNCTION  IDENTIFICATION  AND  RESPONSIBILITY  ANALYSIS 
System  Functions  and  Actors  Identification 

The  first  stage  of  Cube  Tool  consists  of  identifying  the  functions  of  the  system  to  be 
design  'd.  At  this  stage,  the  designer  must  find  out  the  user  needs,  the  type  of  missions  the 
system  will  have  to  accomplish,  and  the  personnel  and  types  of  hardware  and  software  which 
will  be  used.  This  process  requires  intensive  interviews  with  the  user  to  determine  exactly  what 
the  range  of  operations  of  the  system  will  be.  The  missions  that  the  system  is  expected  to  earn.' 
out  are  determined  and  are  used  as  the  basis  for  the  identification  of  the  global  tasks  that  must  be 
executed  for  the  fulfillment  of  a  mission.  These  global  tasks  are  the  system  Functions.  For 
example,  a  system  for  planning  an  air  interdiction  mission  will  have  as  functions  the 
determination  of  the  status  of  allied  forces,  weather  projection,  threat  assessment*  strike 
assessment,  target  prioritization  and  development,  weapon  system  availability,  etc. 
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Then,  each  system  function  can  be  decomposed  in  subfunctions.  The  processing  tasks  an. 
differentiated  from  the  transmission  tasks.  A  processing  task  only  involves  the  processing  of  data 
received  by  an  actor  in  charge  of  creating  or  inferring  new  information.  Transmission  tasks  only 
involve  the  communication  of  information  between  two  different  actors  without  any  alteration  in 
the  content  (for  example  :  digital  communication,  reading  of  a  display,  typing,  or  voice 
transmission).  A  function  can  be  considered  to  be  an  interleaved  sequence  of  processing  and 
communication  tasks,  a  subfunction  can  be  defined  as  a  single  pair  of  a  process  task  and  a 
communication  task.  The  execution  of  a  function  will  require  the  sequential  execution  of  its 
subfunctions. 

Functional  Analysis 

The  initial  specification  of  system  elements,  activities,  and  information  exchange  is  done 
through  functional  analysis  in  the  three  dimensions  of  the  Cube  Tool,  as  shown  on  Figure  2.  The 
three  axes  of  interest  are  : 

•  Functions:  These  are  the  processes  which  have  to  be  executed  for  the  fulfillment  of  the 
mission. 

•  Actors  or  Hierarchical  Levels:  These  are  the  personnel  and  the  hardware  and  software 
nodes  responsible  for  executing  the  different  tasks.  Personnel  are  layered  in 
hierarchical  levels  and  are  most  of  the  time  specialized  per  functional  domain 

•  Time:  This  axis  allows  to  define  on  the  same  time  scale  the  execution  time  of  the 
functions,  their  frequency  and  their  sequence. 


Figure  2  Three  Dimensional  Functional  Analysis 
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In  this  analytical  framework,  a  subfunction  is  composed  of  activities.  An  activity  is  defined 
as  a  process  which  supports  a  given  system  function  and  which  is  performed  by  a  single  actor  or 
hierarchical  level  without  major  interruption.  Therefore,  activities  can  be  part  of  a  processing 
task,  a  communication  task,  or  contain  elements  of  both.  Activities  are  differentiated  according  to 
the  type  of  processing  they  represent  and  which  are  called  roles.  The  roles  considered  by  the 
method  a:\ : 

•  Elaborate  ( E ):  transform  or  generate  information. 

•  Acknowledge  (A):  receive  an  order  important  enough  to  warrant  the  generation  of  an 
acknow  ledgement. 

•  Check  (C ):  receive  a  report  in  response  to  an  order  previously  generated. 

•  Warn  (W')\  receive  an  information  which  does  not  require  taking  any  measures  in  the 
current  mode  of  operation. 

•  Monitor  (Mi:  receive  an  information  on  system  operation  allowing  to  accomplish 
cemm..:td  control  and  communication  resources  management. 

•  Monitor  Lxtcally  (L):  same  as  M  but  on  a  local  basis 

•  Secure  (II):  exchange  of  secured  data  such  as  encryption  keys,  access  keys  and 
certification  mechanisms  of  users  trustworthiness. 

These  activities  can  be  looked  at  from  three  different  perspectives  represented  by  the  analysis 
planes  defined  by  the  three  axes,  as  shown  in  Figure  3.  These  are: 

•  Responsibilities  Plane  (Functions  /  Actors):  This  plane  shows  which  actor  is  in 
charge  of  a  set  of  specific  activities. 

•  Sequences  Plane  (Functions  /  Time):  This  plane  shows  when  (and  how  many  times) 
an  activity  will  be  executed. 

•  Actions  Plane  (Time  /  Actors):  The  plane  of  actions  shows  when  actors  are  busy 
performing  some  activity. 

The  main  analysis  is  performed  in  the  responsibility  plane.  The  roles  which  are  used  most 
and  are  the  only  ones  considered  for  the  requirements  specification  are  E,  A,  C  and  W.  The 
responsibility  plane  is  constructed  by  allocating  the  roles  for  each  subfunction  to  the  different 
actors.  This  allocation  must  verify  the  following  rules: 

•  There  is  one  and  only  one  role  E  per  subfunction. 

•  Except  for  the  first  subfunction  which  starts  the  execution  of  a  function,  a  role  E  can 
only  be  triggered  by  a  role  A  or  C. 

•  The  presence  of  a  role  A  requires  the  presence  of  a  role  C  in  the  column  of  the  actor 
which  has  generated  the  order.  More  generally  the  exchange  which  take  place  from  a 
higher  hierarchical  level  to  a  lower  one  is  done  by  the  presence  of  roles  A,  W. 
Exchanges  which  take  place  from  a  lower  hierarchical  level  to  a  higher  one  are  done 
by  the  presence  of  role  C.  The  pairs  E-A,  E-W  and  E-C  correspond  to  exchange  of 
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information  from  the  actor  performing  the  role  E  to  the  actor  performing  the  other  role 
(A,  W  or  C). 


Figure  3  The  three  Analysis  planes 
This  is  illustrated  in  the  example  shown  on  Table  1. 

Table  1 :  Responsibilities  for  a  Function  with  six  subfunctions  performed  by  four  actors 
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Explicit  exchanges  take  place  across  columns,  between  activities  contributing  to  the  execution 
of  the  same  subfunction  (i.e.,  on  same  row).  Implicit  exchanges  occur  from  row  to  row  between 
activities  performed  by  a  single  actor.  The  interesting  aspect  of  this  methodology  is  that  several 
configurations,  differing  as  to  the  resources  used  or  reflecting  variations  in  operational  needs, 
can  be  represented  in  a  consistent  manner.  This  allow's  to  define  different  thresholds  of 
responsibilities  in  different  modes  (normal  mode  or  emergency  modes)  and  to  point  out  how  the 
reallocation  of  the  tasks  has  to  be  made  among  the  available  actors  when  the  system  switches 
from  one  mode  to  another. 

The  next  section  shows  how  to  convert  the  allocation  of  roles  into  Petri  Nets  and  how  the 
detailed  requirements  of  a  system  for  a  particular  mission  can  be  generated. 
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PETRI  NET  REPRESENTATION  OF  REQUIREMENTS 


The  requirements  of  a  system  are  the  set  of  processes  which  have  to  take  place  for  the  correct 
execution  of  a  mission.  These  requirements  are  scenario-dependent  and  are  most  often  defined  by 
the  set  of  functions  with  their  sequences  and  interrelationships.  In  Valraud  (1989;,  the 
requirements  are  described  by  a  Petri  Net  in  which  system  functions  are  represented  with 
transitions  and  the  data  produced  by  these  functions,  necessary  for  the  execution  of  subsequent 
functions,  with  places.  These  nodes  are  connected  together  to  model  tne  relationships  among 
functions  and  to  show  what  should  be  their  order  of  execution.  This  section  describes  how  to 
develop  more  detailed  requirements  of  a  system  which  take  into  account  not  only  the  different 
processes  which  have  to  take  place,  but  also  the  communication  exchanges  between  the  different 
parts  of  the  system. 

The  Cube  Tool  can  be  used  to  define,  for  each  function,  the  processes  and  the 
communication  exchanges  among  the  different  actors  involved  in  the  execution  of  that  function. 
The  Petri  Nets  depict  graphically  these  processes  and  communication  exchanges  for  each 
function.  When  these  representations  are  linked  together  to  construct  the  requirements,  a  global 
and  consistent  graphical  representation  can  be  defined  that  lets  the  designer  or  the  analyst  take 
advantage  of  the  mathematical  framework  which  underlies  Petri  Nets. 

Representing  the  Responsibilities  for  a  Function  with  Petri  Nets 

As  we  have  seen  in  the  prev-ous  section,  the  first  two  steps  of  Cube  Tool  result  in  the 
definition  of  the  different  system  functions,  their  subfunctions,  and  how  the  activities 
constituting  these  subfunctions  are  allocated  to  the  different  actors  of  the  system.  For  each 
system  function,  the  responsibility  analysis  plane  defines  the  activities  performed  by  the  different 
actors.  From  this  representation,  the  generation  of  the  equivalent  Petri  Nets  representation  of  the 
responsibilities  for  each  function  is  done  in  three  steps. 

In  the  first  step,  each  activity  is  depicted  by  a  transition.  The  transitions  representing  the 
activities  performed  by  the  same  actor  are  aligned  horizontally,  w'hile  the  ones  representing  the 
activities  belonging  to  the  same  subfunction  are  aligned  vertically.  In  other  words,  the  transpose 
of  the  array  of  responsibilities  is  obtained  and  the  non-null  elements  of  this  array  are  transformed 
into  transitions,  as  show'n  in  the  Figure  4. 

A  label  is  attached  to  each  transition  identifying  (1)  the  function,  (2)  the  subfunction  to  which 
the  represented  activity  belongs,  (3)  the  type  of  activity  (E,  A,  C  or  W)  and  (4)  the  actor 
performing  this  activity.  For  example,  in  Figure  4,  the  label  1.3E3  means  that  the  activity 
represented  by  the  transition  belongs  to  subfunction  3  of  function  1,  is  of  type  E,  and  is 
performed  by  actor  3.  In  the  application  described  in  this  paper,  the  subfunctions  are  identified 
by  the  identification  number  of  the  processing  they  represent  throughout  the  system. 
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Figure  4  Drawing  the  transitions  grid 


The  second  step  is  to  add  places  between  the  transitions  representing  the  activities  performed 
by  a  single  actor  and  to  connect  them.  In  this  way,  the  implicit  information  exchanges  which  take 
place  between  the  successive  activities  performed  by  each  actor  are  modeled.  Figure  5  show s  the 
net  obtained  for  the  example. 
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Figure  5  Adding  Implicit  Information  Exchanges 

The  third  step  consists  of  adding  the  information  exchanges  which  take  place  among  the 
actors  for  each  subfunction.  Let  us  recall  that  in  the  Cube  Tool  methodology,  an  exchange 
originates  from  a  role  E  and  ends  at  a  role  A,  W  or  C  and  that  there  is  one  and  only  one  role  E  for 
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each  sub;  unction.  Therefore,  for  each  column  of  the  Petri  Net  representation  obtained  after  the 
two  first  step>.  tire  transition  representing  the  role  E  is  identified  and  is  connected  to  the  other 
transitions  of  the  columns  with  a  connector-place-connector  set.  Figure  6  shows  the  net  obtained 
by  adding  these  explicit  information  exchanges. 


VIE1  1 .201  V6C1 


Figure  6  Add  Explicit  Information  Exchanges 


Modeling  the  requirements  for  a  scenario 

The  procedure >  for  modeling  the  detailed  requirements  for  a  given  scenario  is  shown  on 
Figure  7. 

The  definition  of  a  scenario,  that  is  a  mission  to  be  carried  out.  leads  to  the  specification  of 
the  relationships  and  sequences  of  system  functions.  For  the  fulfillment  of  a  mission,  one  can 
identify  the  system  functions  which  can  be  executed  concurrently  as  well  as  the  functions  which 
will  have  to  be  executed  first  to  trigger  the  execution  of  a  sequence  of  functions.  These 
interrelationships  among  functionsvarv  from  one  scenario  to  another.  Petri  Nets  are  used  to 
represent  the  sequencing  and  concurrency  of  functions  so  that  the  global  requirements  of  a 
system  can  be  derived.  The  procedure  for  determining  the  detailed  requirements  stuns  w  ith  the 
definition  of  the  responsibilities  for  the  chosen  scenario.  To  list  the  functions  on  the  Functions 
axis,  the  slices  (Million. lc>86)  of  the  Petri  Nets  representing  the  global  requirements  are 
computed.  These  slices  represent  the  functions  which  can  be  executed  concurrently.  The 
functions  are  listed  on  this  axis  in  the  order  ot  appearance  in  the  slices  list.  Then,  for  each 
function,  the  actor  which  triggers  the  execution  and  gets  the  final  report  is  identified.  This  actor  is 
designated  as  the  main  one  responsible  for  the  execution  of  this  functions.  Once  the  main  actors 
are  listed  on  the  Actors  axis,  the  responsibility  plane  for  the  scenario  can  be  constructed.  For 
each  function: 

•  A  role  E  is  placed  on  the  cell  defined  by  the  function  and  by  the  main  actor. 

•  Roles  W  are  placed  on  the  cells  defined  by  the  functions  and  by  the  main  actors  who 
are  responsible  for  the  execution  of  the  subsequent  functions  as  determined  by  the 
Petri  Nets  of  the  global  requirements. 
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Figure  7  Procedures  to  Model  the  Detailed  Requirements  of  a  System 


Let  us  consider  an  example  where  there  are  three  functions:  fl,  f2  and  f3,  and  three  actors 
(AL  A2  and  A3).  The  scenario  specification  has  determined  that  fl  and  f2  have  to  be  executed 
before  f3.  The  Petri  Net  is  shown  on  Figure  8  and  the  slices  are: 

Slice  1:  fl.  f2 


Slice  2:  f3 


Figure  8  An  example  of  Global  Requirements  represented  with  Petri  Nets 
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The  responsibilities  specification  of  each  function  show  that  A1  is  the  main  actor  for  fl.  A2 
for  f2.  and  A?  for  f3.  The  scenario  responsibility  plane  is  constructed  by  placing  a  role  E  in  the 
cells  if  1 .  A1 ).  (f2.  A2i  and  (f.3,A3)  and  a  role  W  in  the  cells  (fl,  A3)  and  (f2,  A3),  as  shown  on 
Table  2. 


Table  2  Example  of  Scenario  Requirements 


1 

A3  i 

ffi 

Z  ] 

W  1 

rp> 

i  E 

W  ! 

md 

E"  i 

From  the  information  in  the  scenario  responsibilities  plane,  the  equivalent  Petri  Net  can  be 
constructed  follow  ing  the  same  procedure  that  was  used  for  the  functions.  The  next  step  is  to 
repLu .  C-..T'  ::..r.>i::on  representing  a  function  with  the  equivalent  representation  of  the 
responsibilities  of  this  functions.  By  adding  the  implicit  exchanges  among  actions  for  each  actor, 
the  Petri  Net  of  the  detailed  requirements  is  constructed. 

In  the  next  section,  an  application  of  the  methodology  to  a  system  for  planning  air  interdiction 
missions  is  presented. 


A  PLANNING  SYSTEM  FOR  AIR  INTERDICTION  MISSION 

The  system  used  to  illustrate  the  methodology  is  a  fictitious  one  called  MESACC.  which 
stands  for  Modular,  Endurable,  Survivable,  Austere.  Command  Center  and  which  has  been 
studied  by  Valraud  (1989). 

The  objective  of  an  air  interdiction  mission  system  is  to  plan  operations  against  the  enemy's 
military  potential  before  it  can  be  effectively  used  against  friendly  forces.  These  operations 
restrict  the  combat  capability  of  the  enemy  by: 

•  delaying,  disrupting,  or  destroying  his  lines  of  communications 

•  destroying  enemy  supplies 

•  attacking  fixed,  moving  and  movable  point  and  area  targets 

•  destroying  unengaged  or  uncommitted  enemy  attack  formations  before  they  can  be 
brought  into  the  battle. 

The  result  of  ’hese  operations  is  to  disrupt  enemy  plans  and  time  schedules.  The  integration 
of  air  interdictio  operations  whth  the  fire  and  maneuver  plans  of  surface  forces  is  not  required. 
However,  the:  rnsive  air  operations  are  planned  and  conducted  as  part  of  the  unified  effon  of 

all  friendly  force.:.  'I  >i  re  fore,  air  interdiction  demands  precise  coordination  in  timing. 
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Function  Identification 


The  identification  of  the  functions  of  the  system  requires  the  examination  of  the  context  and 
the  environment  in  which  the  system  operates.  The  context  consists  of  the  geographical 
characteristics  of  the  battle  area.  It  as  assumed  that  the  system  is  operating  in  Europe,  and  more 
specifically  in  the  central  region  (CENTAG).  The  environment  consists  of  the  friendly  forces, 
their  assets,  strength,  current  plans  and  orders,  the  enemy  forces,  their  assets,  strength,  current 
plans  and  orders.  Also,  the  current  weather  is  part  of  the  environment  as  it  is  a  particularly 
important  factor  in  air  interdiction  mission  planning.  The  functions  needed  to  plan  an  Air 
Interdiction  Mission  are  listed  in  Table  3. 


Table  3  System  Functions  of  MES  ACC 


Let  us  describe  briefly  each  of  these  functions: 

•  weather  projection :  This  function  forecasts  the  w'eather  from  the  current  weather 
reports. 

•  format  messages  !  information  fusion  /  update  databases  This  function  transforms  the 
format  of  the  various  data  inputs  into  a  common  format.  The  function  performs  also 
decoding.  Then,  this  function  updates  the  current  information  as  new  messages  come 
in  the  system.  For  example,  if  the  database  contains  the  position  of  a  particular  enemy 
battalion,  and  later  an  intelligence  report  confirms  that  the  battalion  has  moved  to 
another  position,  then  the  function  is  used  to  update  the  position  of  that  battalion,  its 
strength,  and  current  plans. 

•  status  of  allied  forces:  This  function  is  used  to  assess  the  current  state  of  the  allied 
forces,  number  of  troops,  equipment,  and  of  available  aircraft  for  missions. 

•  strike  assessment :  This  function  updates  the  situation  on  the  battlefield,  as  a  result  of 
previous  air  interdiction  missions. 

•  threat  assessment.  This  function  evaluates  the  threat  of  the  enemy  forces  in  the 
different  subareas  of  the  battlefield. 
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•  intelligence  report:  under  certain  circumstances,  reports  from  intelligence  may 
be  requested  when  the  uncertainty  about  some  parameters  of  the  problem  is  deemed 
too  high. 

•  target  prioritization! target  development.  This  function  is  needed  to  prioritize  the  most 
important  objective  to  be  destroyed,  given  the  situation.  The  resources  that  can  be 
used  for  the  next  mission  may  be  scarce  so  that  it  may  not  be  possible  to  allocate 
assets  to  all  objectives. 

•  aimpoint  construction'weaponecring:  This  function  provides  the  coordinates  of  the 
target,  and  allocates  certain  classes  of  friendly  assets  according  to  the  objective  and  its 
intrinsic  characteristics. 

•  penetration! attrition  analysis:  This  function  forecasts  the  degree  of  redundancy  that  is 
adequate  for  each  objective.  Different  platforms  may  be  assigned  the  same  objectiveto 
protect  friendly  assets.  Therefore,  redundancy  insures  a  greater  degree  of  certainty 
over  the  outcome  of  the  mission. 

•  mission  planning:  this  function  delivers  the  final  output  of  the  system  to  the 
environment.  It  consists  of  a  set  of  missions  with  the  objectives,  the  type  of  aircraft  to 
be  used,  its  armament,  the  number  of  aircraft  to  be  used  for  each  objective,  the  route 
to  be  followed,  and  the  time  to  perform  the  mission. 

•  weapon  system  availability:  This  function  describes  what  weapons  are  available  for 
the  mission  at  the  time  it  is  planned.  This  function  tells  w  hat  is  available  according  to 
the  weather  forecasts  (some  aircraft  cannot  fly  under  certain  circumstances),  and  the 
status  of  the  allied  forces  (losses,  use  of  reserves). 

For  the  identification  of  the  actors,  Valraud  (1989)  considers  eleven  workstations,  located  in 
two  shelters,  and  seven  databases.  In  addition,  the  intelligence  center  is  considered  as  an  actor 
providing  the  latest  information  about  the  situation.  In  this  example,  databases  are  considered  to 
be  actors  because  they  are  distributed  and  exchanges  have  to  take  place  on  the  network  to  access 
them.  These  seven  databases  are: 

•  DB-wt:  contains  weather  forecasts  produced  by  fl . 

•  DB-wp:  contains  data  about  weapons  availability,  given  the  status  of  the  allied 
equipment,  and  the  weather  forecasts. 

•  DB-en:  contains  data  about  the  enemy  . 

•  DB-ba:  contains  data  about  the  situation  on  the  battle  field. 

•  DB-st:  contains  data  about  strike  assessment,  i.e.,  the  result  of  f4. 

•  DB-th:  contains  data  about  threat  assessment,  i.e.,  the  results  of  f5. 

•  DB-al:  contains  data  about  the  allied  forces. 

There  are,  therefore,  a  total  of  nineteen  actors  as  listed  in  Table  4. 


Table  4  The  Nineteen  Actors  of  MESACC 


jActor  # 


;  1  !W 


"""Description 


uon  1 


TKoTaiion'1 


[  2  iWorkistaitoh  ^ 

S  3 ;  Workstation T 

(  4'"'1\Vorlcsiaudn  4' 
<  ;  Workstation  5 


For  each  function,  subfunctions  have  been  defined.  Some  of  them  are  used  in  different 
functions  and,  for  clarity,  a  unique  identification  number  has  been  assigned  to  each  one,  which  is 
used  consistently  in  the  figures  and  tables.  The  list  is  given  in  Table  5. 

Table  5  Subfunctions  used  in  MESACC 


Subfunction »:  Description 


Acknowledge 

Request  Weather  jD.ua _ 

Get  Weather  Data 


Deduce  Weather  Projection 


Update  Weather  Data  Base 


Request  Weather  Projection _ 

Get  Weather  Projection 


Request  Allied  Data _ 

Get  Allied  Forces  Data 


Fuse  Allied  Forces  Information 


Update  Allied  Forces  DataBase 


Determine  Allied  Status 


Request  Allied  Report _ 

Get  Allied  Report 


Request  Enemy  Forces  Data 
Get  Enemy  Forces  Data 


17  !  Fuse  Enemv  Forces  Information 


Update  Enemy  Forces  DataBase 


_ 19  j  Request  Enemy  Report _ 

20  !  Generate  Enemv  Report 


Request  Battlefield  Data 


Get  Battlefield  Data 


23  i  Fuse  Battlefield  Information 


24  ;  Update  Battlefield  DataBase 

25  !  Request  Battlefield  Report 


26  i  Generate  Battlefield  Report 


ISuhfunction 


27 


2S 


29 


30 


31 


Descri 


Requcsrjhrikc  Assessment  Data 

Get  Strike  Assessment  Data _ _ 

Assess  Strike 


Request  Strike  Report 


Generate  Strike  Report 
1  Request  Threat  Assessment  Data 


Get  Threat  Assessment  Data 


Update  Threat  Assessment  DataBase 


*  Modify  Threat  Assessment _ _ _ 

Rank  Threats 


Get  Targets  list _ 

Request  Available  Weapons 


Get  Ayailabje  weapons _ 

Request  Weapon  Data 


Gel  Weapon  Data 
Generate  new  We  a - - - 


Request  Current  Intelligence 


Gel  Current  Intelligence 


Perform  Analysis 


Request  Penetration  Analysis 


Get  Penetration  Analvsis 


Plan  Mission 
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Responsibility  Specifications  for  each  Function 

The  allocation  of  roles  is  illustrated  for  function  f3.  Status  of  Allied  Forces.  To  determine  the 
status  of  allied  forces,  Workstation  WS7  needs  to  get  information  from  the  battlefield  a..d  to 
deduce  from  the  last  state  of  the  allied  forces  the  new  status.  Therefore,  WS8  is  queried  to  obtain 
a  battlefield  report  (subfunction  "Request  Battlefield  Report”).  To  do  this,  WS8  has  to  access  the 
database  Battlefield  (subfunctions  "Request  Battlefield  Data"  and  "Get  Battlefield  Data")  to  make 
the  report  that  it  sends  to  WS7  (subfunction  "Generate  Battlefield  Report”).  According  to  the  data 
that  WS7  has  just  received,  WS7  accesses  the  allied  forces  data  base  (subfunction  "Request 
Allied  Data"  and  "Get  Allied  Data")  to  determine  the  new  status  of  the  allied  forces  (subfunctior 
"Determine  Allied  Status").  Once  this  is  performed,  the  allied  forces  database  has  to  be  updated 
(subfunctions  "Update  Allied  Forces"  and  "Acknowledge").  The  responsibility  analysis  plane  is 
shown  on  Table  6. 


Table  6  Responsibilities  for  Function  f3 


\  0  Status  of  Allied  Forces 

j  Actor*  I  7  j 

~’S“” 

16TT<»“1 

I’SubT*  I  SuViTunction 

1  Actor  1  WS7  1 

WSS 

DB-rxi  DB-aii 

1  25  Request  Battlefield  Report 

„  j  F-  1 

A  _ 

1  J 

|  21;  Request  Battlefield  Data 

i  1 

f: 

A  !  1 

1  22iGet  Battlefield  Data 

L  _ L 

c 

E  S 

1  R  Request  Allied  Data 

F. 

|  I 

- 

9?  Gel  Allied  Forces  Data 

— k4 

!  El  i 

125  Determine  Allied  Statu- 

1 

i  lj  (update  Allied  Forces  Da'.aB 

ISC  |  1*.  | 

!,  A  j 

1:  Acknowledge 

i  c  i 

Figure  9  displays  the  Petri  Net  deduced  from  this  responsibility  analysis  plane. 


3  25E7  3  26C7  3  8E7  3  9C7  3.12E7  3  11E7  3  1C7 


Figure  9  Petri  Net  for  Function  f3 

By  performing  the  same  analysis  for  the  other  functions,  the  responsibilities  planes 
described  on  Tables  7  to  15  and  the  Petri  Nets  displayed  on  Figures  10  to  19  are  obtained. 
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Function  1 :  Weather  Projection 

Table  7  Responsibilities  for  Function  fl 


fl  Weather  Projection  j  Actor# 

T . 

nr 

Suhfit:  Sublunction  }  Actor 

Wsl 

Dh-wt 

Z  Request  Weather  Data 

E 

A 

3i  Get  Weather  Data 

c 

E 

41  Deduce  Weather  Protection 

E 

5i  Update  Weather  Dala  Base 

A 

__ _ 11  Acknowledge _ 

C  j  E 

1.2E1  1.3C1  1.4E1  1.5E1  1.1C1 


Figure  10  Petri  Net  for  Function  fl 

Function  2:  Format  Messages!  Fusion  of  I  nformation/Update  Database 

Table  8  Responsibilities  for  Function  f2 


8!  Request  Allied  Dala _ 

9:  Gel  Allied  Forces  Data 


JOj  Fuse  Allied  Forces  Information 
1 1 ;  Update  Allied  Forces  DataBase 
1  ]  Acknowledge _ 


- — 


1  16 

Get  Enemv  Forces  Data 

L _ 22 

Fuse  Enemv  Forces  Information 

1 _ IS 

Update  Enemv  Forces  DataBase 

!  1 

Acknowledge 

f  21 

Request  Battlefield  Data 

|  22 

'Oct  Battlefield  Data 

1  23 

Fuse  Battlefield  Information 

| _ 24 

Update  Battlefield  DataBase _ 

i . f 

Acknowledge 

2  15E7  2.16C7  2  17E7  2  18E7  2.1C7 


2.21E8  2  22C8  2.23E8  2.24E8  2  1C8 


Figure  1 1  Petri  Net  for  Function  f2 


Function  4:  Strike  Assessment 

Table  9  Responsibilities  for  Function  f4 


Ii4  Strike  Asscsmcni  |  Actor* 

7 

15 

8 

17 

18  j 

ISubfs  j  Subfunction  j  Actor 

WS7 

DB-cn 

\VS8 

DB-st 

DB-tiii 

2 7j  Recuiest  Strike  Assessment  Data 

E 

A 

j 

28i  Oct  Strike  Assessment  Data 

C 

E 

3 

19;  keenest  Enemy  Report 

A 

E 

< 

15:  Keotie't  Encm\'  Forces  Data 

E 

A 

1 

1  ft;  Get  Encntv  Forces  Data 

C 

E 

-  * 

i  201  Generate  Enemv  Report 

E 

C 

i  33;  Reciuest  Threat  Assessment  Data 

E 

A  ! 

j  34:  Get  Threat  Assessment  Data 

C 

E  1 

i  24;  Assess  Strike 

E 

| 

•  ?o:  Update  Strike  Assessment  DataBase 

E 

A 

] 

1  i :  Acknowledge 

C 

j 

4.19A7  4.15E7  4.16C7  4.20E7 
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Function  5:  Threat  Assessment 


Table  10  Responsibilities  for  Function  f5 


.liircgfAssesmcnt _ lAcicrtf 

! _ Subfunclion  - _ |  Actor  j  1 

Request  Threat  Assessment  Data  j 

;  Get  fnreat  Assessment  Data  j 

{Request  Enemy  Report  '  i~" 

|  Request  Enemy  Forces  Data  j 

J  Gct_Enemj[  Forces  Data _ 1 


>;  Request  Battlefield  Report _ 

i  Request  Battlefield  Data 
'J  Get  Battlefield  Data 
r  Generate  BaiUeMdRejiqrt 
'j  Update  Threat  Assessment  DataBase 
!  Acknowledge 


i  IS  j 
i  DB-ih; 


St9A?  S15E7  5  16C7  5  20E7 


I  isAlU-S  16E15 


S25A8  S21E8  S  22C8  S  26E6 


5  2^  b 22£ ' 6 


5  33E5  5  34C9  4  l90ft>LS  1 5C9 


S  20C9  \25E9 


S26C9  5  35E9  5  3C9 


5  5  1E*8 


Figure  1 3  Petri  Net  for  Function  f5 

Function  6:  Current  Intelligence 

Table  1 1  Responsibilities  for  Function  f6 


[f6 _ Current  Intelligence _ Actor#  _ 9 _ 12  ■ 

j  Subf*  j _ Subfunction _ Actor"  WS9  DMC~| 

•  4  6[  Request.  Current  Intelligence _  E _ A  t 

i  47|  Get  Current  Intelligence _ C _ E  j 

1  36i  Modify  TTrreal  Assessment  E  ; 


6.46E9  6.47C9  6.36E9 


6.46AV124.  6.47E12 


Figure  14  Petri  Net  for  Function  f6 
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Functe  m  7:  Target  Prioritization/Target  Development 

Table  1 2  Responsibilities  for  Function  f7 


iO  Tarcet  Develop. /i’riorit.  i  Actor* 

2 

. ?. 

yt~\ 

Subf*  j  Subfunction  i  Actor 

"  WS2 

WS6 

'DB  bat  DB-th: 

33;  Request  Threat  Assessment  Data 

E  , 

1  A  | 

34<  Get  Threat  Assessment  Data 

[  E  i 

;  2 51  Request  Battlefield  Report 

E _ 

ij 

1  i 

'  2l|  Request  Battlefield  Data 

C 

_E_ 

_ 1 

••  22i  Get  Battlefield  Data 

L  Cl 

1  26;  Generate  Battlefield  Report 

c 

E 

ZltZJ 

j  37',  Rank  Threats  _ _ 

me 

S  1 _ j 

7.33E2  7.34C2  7.25E2  7.21C2  7.26C2  7.37E2 


Function  8:  Aimpoint  Construction/  Wcaponeering 

Table  1 3  Responsibilities  for  Function  f8 


FfS  Aimpoint  Construct.AVeapon 

Actor# 

...  ~  j 

j  Subfsj  Subfunction 

Actor 

\VS4  j 

[.  4  Si  ..Aimpoint  Construction  Wcaponeering 

E  i 

8.48E4 

04^0 


Figure  16  Petri  Net  for  Function  f8 
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Function  9:  Penetration1  Attrition  Analysis 

Table  14  Responsibilities  for  Function  f9 


rr 

TT 

17  _ 

. To"' 

19 

iSubf«|  Subfunction  i  Actor 

WS3 

WS6 

DB-cn 

DB-sr 

WS10 

DB-al 

;  19s  Request  Enemy  Report 

E 

■  M 

w 

mm 

1 5l  Request  Enemy  Forces  Data 

"  ’“r 

El 

■ 

E 

161  Get  Enemy  Forces  Data 

|  | 

E 

21  H 

C 

I  20j  Generate  Enemy  Report 

C 

|  I 

■  ■ 

■  ■ 

E 

|  3 1‘  Request  Strike  Report 

5^2 

mm 

1  27s  Request  Strike  Assessment  Data 

mm 

jjjjn 

5 

A 

j  28J Ciet  Strike  Assessment  Data 

c 

E 

|  32l Generate  Strike  Report 

c 

E 

mm 

mi 

flj 

8!  Request  Allied  Data 

9m 

|j 

A 

?  9s  Get  Allied  Forces  Data 

MM 

M  H 

■  ■ 

m 

■ 

E 

1  49i  Perform  Analysis 

■5 

mm 

mm 

mm 

■ 

9.19£3 


9.23C3  9.31E3  9.27C3  9.32C3  9.SE3  9  9C3  9  49 


Ficure  17  Petri  Net  for  Function  f9 


Function  10:  Mission  Planning 

Table  15  Responsibilities  for  Function  flO 


fl()  Mission  Planning 


IaumJ _ 1 _ l . . i . 


t).  ub.fl?. .. . Subluocuoiiww. 

38i  Request  Targets  List 

391  Get  Targets  list 
40;  Request  Available  Weapons 
4ll  Get  Available  weapoas 


7|Get  Weather  Projection 


Actor  [  W  S 1  i 


WS2I  WS3  j  WS4  j 
A  j  'T  E 


WS5 


50j  Request  Penetration  An al vs is_ 
51?  Get  Penetration  Analysis 


1 


52;  Plan  Mission _  _  j _ |  j _ 1  E 


21 


ICfA'  107F’ 


Figure  18  Petri  Net  for  Function  flO 


Function  11:  Weapon  System  Availability 

Table  16  Responsibilities  for  Function  fl  1 
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Figure  19  Petri  Net  for  Function  fl  1 


The  Global  Functional  Requirements 

A  specific  scenario  is  considered  next.  It  is  assumed  that  the  hostilities  started  two  days  ago. 
Although  the  enemy  has  gained  ground  on  the  battlefield,  the  friendly  forces  resist  the  pressure, 
and  major  assets  in  reserve  have  not  been  committed  on  either  side.  The  conflict  is  a  conventional 
one.  The  friendly  forces  and  the  enemy  forces  have  both  fairly  accurate  information  about  the 
situation  on  the  other  side.  Each  side  knows  what  the  resources  are  on  the  opposing  side,  as  well 
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as  the  location  of  these  assets,  although  some  uncertainty  remains.  In  certain  areas,  the  battle  line 
is  difficult  to  assess.  Therefore,  there  is  a  need  to  use  MESACC  to  plan  long  distance,  high 
altitude  interdiction  missions.  Since  the  conflict  started  two  days  ago,  the  database  already  exists. 
All  the  other  functions  described  earlier  are  in  use. 

The  various  data  inputs  from  the  sensors  are  weather  reports,  reports  on  friendly  and  enemy 
forces  (strength,  position,  status),  combat  reports,  request  from  the  local  Command  Center  for 
assistance,  mission  reports,  and  current  and  future  operations  plans.  The  output  is  unique  and 
consists  of  air  interdiction  mission  plans.  The  interrelationship  between  the  various  functions  is 
as  follows: 


It  should  be  understood  that  this  description  of  the  interrelationship  between  functions  is 
purely  functional.  If  a  function  is  derived  from  another,  it  does  not  mean  that  the  input  of  that 
function  is  sufficient.  Indeed,  data  from  the  context  may  be  necessary  (terrain  information  for 
example).  The  global  functional  requirements  of  MESACC  are  described  by  the  Petri  Net  of 
Figure  20.  This  Petri  Net  contains  only  one  switch,  si,  which  represents  the  optional  use  of  the 
"Current  Intelligence"  function,  f6. 


fi 


Figure  20  MESACC:  The  Global  Functional  Requirements 


Detailed  Requirements 

The  Petri  Net  obtained  from  the  global  functional  requirements  is  used  to  determine  the 
slices  of  the  Net.  The  slices  are: 

Slice  1:  fl.f2.  Slice  5:  f7.  f9. 

Slice  2:  f?.  f5.  Slice  6:  f8. 

Slice  5:  fo.  Slice  7:  flO. 

Slice  2:  f a.fi  i . 

To  determine  how  data  are  transmitted  among  functions.  Cube  Tool  has  to  be  applied  once 
more.  The  purpose  is  to  define  the  global  responsibility  for  the  scenario.  In  the  definition  of  the 
responsibilities  for  each  function,  only  one  actor  triggers  the  execution  and  gets  the  final  report. 
By  looking  at  the  global  functional  requirements,  and  at  the  different  responsibility  planes,  one 
can  identify  where  the  output  of  each  function  has  to  be  sent  in  order  to  generate  the  Scenario 
Responsibilities  Plane  show  n  on  Table  17.  The  derived  Petri  Net  is  show  n  on  Figure  21. 

Table  17  Scenario  Responsibilities 


Figure  2 1  Petri  Net  of  the  Scenario 
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The  representation  of  the  detailed  requirements  is  obtained  (1 )  by  replacing  each  transition 
containing  the  letter  E  with  the  Petri  Net  representation  of  the  responsibilities  of  the  functions  this 
role  E  models  and  (2)  by  adding  the  implicit  information  exchanges  between  the  functions 
performed  by  a  single  actor.  Figure  22  displays  the  detailed  requirements  of  MESACC. 

CONCLUSION 

Cube  Tool  has  been  extended  from  functions  to  systems.  A  methodology  for  deriving 
structural  requirements  has  been  proposed.  It  is  used  to  represent  with  the  Petri  Net  formalism 
the  processes  and  communications  which  take  place  for  the  correct  execution  of  a  mission.  This 
methodology  fills  a  gap  between  the  description  of  requirements  and  the  quantitative  models 
needed  for  the  analysis  and  evaluation  of  C3I  systems  designs. 
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